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In recent years an extended form of com- 
puting has emerged, called mobile dis- 
tributed computing, in which users interact 
with many different mobile and stationary 
computers over the course of the day. Com- 
putation no longer occurs at a single location in a sin- 
gle environment, but rather spans a multitude of 
situations covering the office, meeting room, 
home, airport, hotel, plane, etc. 

A significant aspect of this emerging mode of 
computing is the frequently changing execution envi- 
ronment to which users and long-running appli- 
cations are exposed. As users move about, the 
sets of mobile and stationary objects they interact 
with may change, producing a highly dynamic 
execution environment in which location is impor- 
tant. Location information is necessary for users and 
applications that want to query and interact with 
nearby devices and services. Such information 
also allows stationary clients to track moving objects. 
In general, location information enables software to 
adapt according to its location of use, the collec- 
tion of nearby people and objects, as well as the 
changes to those objects over time. We use the 
term context-aware computing to describe software 
exhibiting these general capabilities. Articles 
about this general topic include (4, 11-14]. 

This article focuses on the communication issues 
we have encountered in disseminating location-based 
information to interested clients. We introduce 
the notion of an active map service (AMS) that 
publishes location information for objects in a region. 
We shall use the term located-object to refer to 
the entities managed by an active map service. Locat- 
ed -objects are descriptions of anything that has 
an associated physical location. Examples of 
locatedobjects include persons, printers, terminals, 
and workstations, as well as location-dependent 
services, such as information agents associated 
with particular parts of a store or building. 

A key issue that we have faced in building an active 
map service is that of scale. A variety of issues must 
be dealt with in order to av id overloading the AMS, 
its clients, and the communication facilities that 
j in them: 

• Large meetings of mobile users may cause con- 



siderable traffic because context-aware clients 
at the meeting as well as remote applications may 
need to be informed of the frequent occupant 
changes. High message volume may also occur in 
high traffic locations such as building lobbies. 

• Low bandwidth links (usually wireless) limit the 
amount of information that can be sent to some 
clients. 

• Mobile hosts have significantly stricter resource 
budgets and hence cannot do as much work as 
other hosts. For example, concern for power 
conservation may limit the activity that battery- 
powered hosts are willing to perform on an 
ongoing basis. 

Unfortunately, simply partitioning the AMS 
into many servers, each managing a small area, is 
only a limited help because clients frequently 
desire to know about information covering an entire 
region whose size is independent of what might 
be most suitable for the AMS. This is illustrated 
by the common ways we have observed clients 
using location information: 

• Many users may wish to track a particular locat- 
ed-object as it moves around a region. Exam- 
ples include tracking a co-worker you wish to 
talk to and tracking the office coffee cart in 
order to be made aware when either is nearby. 

• More often users wish to track located-objects 
with a specified set of attributes in a particular 
region. An example is tracking all members of 
a workgroup. 

• Users may want to find the located-object near- 
est to a specified location (usually their own) 
that meets a specified set of constraints. Exam- 
ples include finding the nearest printer and 
finding the nearest system administrator. 

• Finally, users frequently wish to monitor activi- 
ty at a particular location. A typical example is 
keeping track of available display devices at 
one's current location. 

Of the four examples, the first three represent 
regional queries that will require the AMS to 
cover a region whose size is Ukely to be that of a build- 
ing or small campus, irrespective of how the 
AMS' implementation docs so. 

An architecture that addresses these issues is 
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the primary focus of (his article. The worst -case usage 
scenario that our architecture will be designed to 
handle is the "meeting scenario" in which several 
hundred people, all using context-aware applica- 
tions, converge on an auditorium over a period of 
several minutes. To illustrate some of the issues 
involved, consider how location information 
about this scenario might be disseminated to the peo- 
ple involved: the simplest — a naive unicast approach 
— would result inn updates going to each of n clients, 
which quickly gels out of hand. Waiting for quies- 
cence and batching the updates would reduce the 
message count to n, but would sacrifice timeli- 
ness. Using broadcast or multicast [3) for the updates 
would reduce the aggregate message traffic even 
further, but would likely increase the traffic seen 
by some clients, since not all clients are interested 
in exactly the same information. This increase 
may be problematic for clients residing on small hosts 
(such as PDAs) or that are connected via low- 
bandwidth links. 

Each of the approaches exhibits different 
trade-offs of server, network, and client loads. To 
solve the problems of controlling and balancing com- 
ponent loads we use a combination of three tech- 
niques: detection of sets of clients that alt wish to 
receive the same information; dynamic assign- 
m nt of client sets to multicast groups; and update 
suppression to guarantee clients that their com- 
munication links will not be overloaded. The next 
section describes context-aware computing, active 
maps, and our system model in greater detail. 
The section following that presents our design for 
disseminating active map information, the next 
section describes the performance of a testbed imple- 
mentation we have done, then we describe relat- 
d work, and the final section summarizes our 
work and presents our conclusions. 

Con text-Aware Computing and 
Active Maps 

Context-Aware Computing 

Context-aware computing is the ability of a 
mobile user's applications to discover and react 
to changes in the environment they are situated 
in. In our system mobile users run software that is 
constantly monitoring, or subscribing to, informa- 
tion about the world around them. This monitor- 
ing is done for a variety of reasons, including: 

• To provide a display of "interesting" located- 
objects. 

• To keep a record of located-objects and per- 
sons one has encountered, for use by applications 
such as "activity-based information retrieval/* 
which uses the context at the time the data was 
stored to assist in retrieval [7]. 

• To detect location-specific information, for exam- 
ple electronic messages left for the user or for' 
public perusal. 

• To keep a look out for nearby devices that can 
be used opportunistically by applications, such 
as additional display terminals in a room. 

• To detect nearby people, located-objects, or ser- 
vices that are relevant t reminders or actions 
set to be triggered by their presence. 
Further descripti nsofa variety of location-based 

applications can be found in [4, 12]. We describe one 



particularly illustrative application here in more 
detail: the locations program. This program displays 
located-objects for a region as a textual list or as 
a map marked with descriptive icons. M Interesting 
located-objects" usually means persons who have 
chosen to make their present location publicly avail- 
able (within, say, the confines of their office 
building or organization), although any set of objects 
for which location information is-a-vailable — 
such as printers and copiers — can also be displayed . 1 
When a mobile object, such as a person, moves, 
the associated information is updated on the 
locations display. 

One important aspect of the locations program 
is that in crowded meeting rooms or large regions 
filtering must be done in order to obtain a manageable 
amount of information to display. Thus, the 
information that clients are actually interested in 
is a subset of all the location information that 
might be available to them. Where and how fil- 
tering is done will turn out to be an important 
issue for controlling the behavior of our system. 

Users of our system employ and interact with a 
heterogeneous and changing set of hosts. In addi- 
tion to using stationary hosts and I/O devices, 
they may also carry wireless PDAs and notebook 
computers. Consequently, context-aware applica- 
tions must be able to run on both small mobile hosts 
as well as the more traditional (and more powerful) 
stationary ones. Furthermore, they must be prepared 
to deal with a variety of different network media, 
from relatively slow wireless links to very high-speed 
LAN links. 

Mobile users also expect to be able to monitor 
regions other than the one immediately surroundi ng 
them and expect to be monitorable themselves by 
remote parties. For example, a person visiting a 
remote site might wish to have their present location 
be known to an agent process running back at 
their home site so that interested parties can 
determine where they are. Similarly, that person 
might wish to monitor various activities occurring at 
their home site, such as the presence or absence 
of a colleague whom they wish to call by phone. 

Active Maps 

The AMS represents located-objects as tuples of 
key-value attribute pairs. Any kind of information 
that a client wishes to make publicly available can be 
stored with a located-object registration; howev- 
er, every located-object must include a location 
attribute that describes its current physical location. 

An active map consists of a hierarchy of loca- 
tions with a containment relation; for example, rooms 
are contained in buildings and buildings are con- 
tained tin a region. Figure 1 shows an example 
hierarchy. An AMS region is the set of locations main- 
tained by a single active map server. The detailed 
structure (and depth) of any region's location 
containment hierarchy is region-specific. 

The focus of our work so far has been on providing 
useful location information for AMS regions that 
cover localized, administrative entities, such as build- 
ings or small campuses. This is because we believe 
the located-objects most useful for context-aware 
computing are close at hand, either collocated or 
requiring a short time to get to. Context -aware appli- 
cations are more likely to monitor the contents of 
the room and building they are situated in than 
the contents of a building in the next town. 
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' The privacy issues sur- 
rounding who may gain 
access to someone else's 
location information are 
beyond the scope of this 
article ami are addressed 
in f!2J. Our work is based 
on the observation that 
many people are willing to 
make at least a limited 
version of location infor- 
mation available to co- 
workers within the 
confines of their work- 
place. 
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I Figure 1. Example of active map containment hierarchy. 



2 This assumption holds 
m practice because the 
AMS receives information 
about changing objects 
via RPC and processes 
each RFC in turn. 

3 See 1121 for more infor- 
mation on how user 
agents fit into our system 
design. 



Because of the emphasis on proximate infor- 
mation, we do not address the question of how to 
manage information over larger regions, such as 
cities or countries. Instead, we assume that clients 
will accept the burden of interacting with any and 
all AMS regions they are interested in. An impor- 
tant consequence of this approach is that we must 
be able to scale the implementation of an AMS 
service to cover regions the size of buildings and 
small campuses so that "regional" queries can be 
implemented in an efficient fashion. 

Clients of the active map service "publish 
information about objects at a particular location 
and/or submit queries to obtain information 
about other published located-objects. Queries 
are matched against the attribute keys and values 
of located-objects stored in the AMS. Standing 
queries, called "subscriptions" can also be specified; 
the AMS will send information as it changes over 
time to subscribing clients. 

Receiving updates in response to subscriptions 
is the common way clients interact with the AMS. 
To characterize this form of interaction more 
precisely, we define the AMS as a set of "publica- 
tions": P = <Pi.P2> • .Pm> This is the set of 
located-objects for which the AMS maintains 
information. Any client, i, can specify interest in a 
dynamically changing subset of Ps publications 
by submitting a subscription query, S,. The set of 
all such subscription queries is denoted by 5. All 
members of 5 are run against P whenever the 
state of any member of P changes. We assume 
that at any given time, f, at most one member of P 
will change its state. 2 If a member of P changes at 
time / then the set of subscription queries match- 
ing the object is denoted the update query set, 
u Q (t). The associated set of clients who should receive 
notification of the change is denoted the updateclient 
set, w^f). 

To illustrate how the AMS works we describe two 
examples. Inthe first, mobile users com inualty mon- 
itor their current locations for various reasons, 
such as those outlined in the previous section. In our 
system the personal informal ion for each user is man- 
aged by a user agent process. 3 Mobile users employ 
the user agents t monitor the user's whereabouts 
by various means and publish that information in the 
AMS. The user agent for a user U t who leaves 
location M and enters location 12 might perform 
the following AMS operations: 



• Cancel publication of ITs presence at /I. 

• Cancel subscription that notifies of changes to any 
objects located at /l. , . _ 

*■ Publish ifs presence at 27. 

• Subscribe to be notified of changes to any 
objects located at 12. This subscription returns the ; 
current set of objects at a as its return value, f 

■ If any other* clients of the. AMS were momtor- ; 
ing either location /I or location 12 then these 
clients would be notified of user Ifs movement. 

For example, assume that user U\ is at location 
l\ and users U2 and 1/3 are at location tl and that 
all are running user agents that have placed sub- 
scriptions with the AMS to monitor their present 
locations. When U leaves location II the AMS 
will notify the user agent of U\ that U has left. 
Similarly, when U enters location 12 the AMS will 
notify the use r agents of U2 and U3 about tys arrival. 

The second example is the implementation of the 
locations program, described earlier. This pro- 
gram issues subscriptions to the AMS in order to 
be notified of changes to relevant located-objects 
anywhere in a specified region. The region might 
be the entire AMS region or a smaller sub-region 
if the AMS* location hierarchy contains smaller inter- 
nal regions (such as the floors of a building). To obtain 
information about only people the program 
would restrict its subscription query to match 
located-objects that have, for example, the key-value 
attribute pair (key » 'type,- value = 
•person*). 

System Model 

The context-aware applications, active map service, 
and examples we have described require several 
things from the underlying system infrastructure. 
In particular, we assume that suitable location 
sensing facilities are available to track the locations 
of mobile objects and that suitable databases are 
available that describe the locations of stationary 
objects of interest. The system deployed in our 
laboratory uses several different technologies to 
detect the locations of mobile objects (mostly 
people): 

• Active badges [13], are attached to mobile 
objects and monitored by sensors embedded in 
the ceilings of rooms and corridors. 

• Input activity at keyboards and mice is moni- 
tored to detect the presence of logged in users 
in front of stationary workstations. 

• Nano-cell-based diffuse infrared communications 
[2, 10], is used to communicate with PDAs and 
provide room-sized cell location information. 

• Nano-cell-based, radio communications (6], is 
used to communicate with portable notebook 
computers and provide roughly room-sized cell 
location information. 

Location information for each person is syn- 
thesized from these various sources by t he user age nt 
for that person. A person's user agent may then pub- 
lish location information to the AMS, subject to 
any privacy constraints the user has set. 

In addition to the availability of location-sensing 
facilities, we also assume that AMS clients can be 
reached by packet-based communications, such 
as IP. This requires that applications on mobile hosts 
are able to use a form of "mobile IP" communi- 
cati ns protocol [5], or employ a"mobile host-agent 
architecture"[lO]. These approaches deliver 
messages t mobile h sts in different ways. For 
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mobile IP, message delivery is a network func- 
tion, whereas the host-agent architecture uses a well 
known user process as an intermediary to track, 
forward, and possibly filter packets in an appro- 
priate manner. 

In addition to assuming that packets can be 
routed to mobile hosts we also require efficient mul- 
ticast communications. Although currently there is 
no standard combined mobile-multicast commu- 
nications protocol, one can imagine extending the 
current mobile IP protocols to support multicast [ I ]. 
Throughout most of this article we will assume that 
mobile-multicast is supported throughout the sys- 
tem. In the section on unicast wireless links, we 
discuss the implications of relaxing this assumption 
to allow the use of unicast-only wireless links. 

Disseminating Active Map 
Information 

Basic Unicast Design 

The simplest implementation of an active map 
service involves using reliable unicast communi- 
cations, such as remote procedure call (RPC), 
between the AMS and its clients. Most of the time 
and for most clients RPC is a satisfactory commu- 
nications paradigm to use. The reason is that, for 
the most part, there are not that many objects 
moving around and subscribers of the AMS are either 
directly connected to high-speed networks or are not 
sharing their slow-speed communication link with 
many others. There are not many objects moving 
around because people are the primary movable 
"located-object" in the system and most of the 
time they are stationary. Furthermore, most of the 
time people are ensconced in separate offices or cubi- 
cles and hence any wirelessly connected comput- 
ers they have are likely to occupy different nano-cells 
in isolation. Of course, there are significant numbers 
of workplaces for which these assumptions of 
mostly stationary, mostly separated, people do not 
hold. Similarly, not all wireless technologies employ 
room-sized cells for their communications. 

Brief periods of increased load can be handled 
by simply letting the unicast design queue AMS 
update messages for later transmission and by 
batching together multiple updates. Two benefits 
are gained this way: 1) the packet overhead of an 
update message can be amortized over more update 
items, and 2) if the interval between updates 
spans several sightings of the same moving object 
then fewer update items can be sent by only 
including the latest sighting for the object. 

The disadvantages of this approach are that 
subscribers obtain their information in a less 
timely fashion and that they obtain less accurate 
information about the activity around them. This 
is a problem, for example, because a client may 
find out too late or not at all that someone the 
client wanted to know about has passed nearby. Dis- 
carding updates also requires some additional 
message processing by the AMS. In any case, this 
approach to controlling overload works only if 
the overload lasts for a brief period of time. 

A Reliable Multicast Design 

Much of the AMS load generated during overload 

situations is due to sending the same update mes- 



sage, over and over again, to many different sub- 
scribers. This duplication can be eliminated by 
employing multicast to distribute the update message - 
to all interested subscribers at the same time. 

We shall refer to the data structure needed inside 
the AMS to implement reliable communications 
to a particular multicast group as a multicast 
channel. The AMS multicast channels-implement 
a standard negative acknowledgment protocol. 
To support this, each multicast message contains 
a sequence number. Receivers check to make 
sure they see each sequence number in turn. If a 
missing message is discovered, then the receiver 
sends a "heal" request specifying the missing 
sequence number. The sender then retransmits 
the requested message in a heal response. In order 
to bound the time it takes receivers to detect a missed 
message, whenever there is no normal message traf- 
fic for longer than the "synchronization interval," 
a "synchronization" message is sent. Under high load 
situations waiting for synchronization messages 
to detect misses rarely occurs since data messages 
perform the same function. 

Using a Single Multicast Channel — The 

AMS sends out asynchronous notifications, or 
callback messages, that contain information 
about the changing context. Using a single multicast 
channel for alt callback messages minimizes the 
AMS load. The information about a located-objecf s 
change-of-state can be sent once instead of once 
for each client whose subscription query matches the 
event. For network segments having multiple clients 
the load would also be minimized, since identical 
messages occur only once. 

However, this reduction in server and network 
load comes in exchange for additional load placed 
on all clients and on some communication links. This 
is because all clients — and the communication links 
joining them to the AMS — now receive alt 
updates the AMS sends out. For clients that are power 
conscious and/or attached to slow communica- 
tions links (e.g., a PDA attached to a 19200 bps 
infrared link) this solution is unacceptable. 

Multiple Multicast Channels — Instead of 
indiscriminately sending update information to 
all clients one can use multiple multicast channels 
in order to send out information to selective 
groups of clients. This requires that the AMS be able 
to figure out how to assign some or all updates to one 
or more multicast channels to be used for dissem- 
ination. 

The AMS must, of course, also tell subscrip- 
tion clients which multicast channels to listen to first. 

We define the general multicast-channel assign- 
ment problem as follows. Recall the definition of 
the AMS previously as a set of publications, /\ a 
set of subscriptions, S, and update client sets, u e . 
Let G = (gj, g 2 . • • • » &t> De a collection of multi- 
cast channels. We desire to define a mapping, 
#u(tY **c(0 G* of u c (/) onto C, such that if the clients 
specified by u c (t) listen to the multicast channels 
specified by tf u {t) at time / and the AMS sends 
out the update information intended tor u c (t) to 
the multicast channels specified by M u (t) at time t 
then the following wilt hold: 
• Every subscription client / will receive the update 

information it has specified with its query, S, % 

and 
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4 Clients may withdraw 
subscriptions and sub- 
scriptions are also garbage 
collected when their sub- 
mitting clients are detect- 
ed to have gone away. 



• The overall "system overhead** of disseminat- 
ing update information will be minimized. 
Unfortunately, when considered in its full gen- 
erality, there are a variety of system overheads to 
consider when choosing * u {t). Furthermore, 
these overheads are borne by different parts of 
the system and are only partly comparable to 
each other 

• The AMS bears the cost of computing/4f u (/), send- 
ing updates about changes to P> and dissemi- 
nating MJj). 

• Clients bear the cost of tracking changes to 
rf u (t), as well as filtering unwanted updates. 

• Duplicate update messages put additional load on 
communication links. 

• Notification lime is affected by the use of extra 
messages. If the AMS sends multiple messages 
for the same update information then that will 
introduce a delay for all but the first group of recip - 
ients. This is a cost borne by the clients. 
Given these different cost metrics it is difficult 

to define what minimum system overhead means. 
Worse yet, even if we restrict the problem by 
choosing a particular cost metric, it will likely not 
be easily solvable in general. For example, we 
might choose to minimize server and communica- 
tion costs by requiring that every update be sent using 
exactly one message. That is,/* u (t) would be restrict- 
ed so that every update client set, u c (i)» is mapped 
to exactly one member of G. In this case minimiz- 
ing system overhead would mean choosing/*^/) such 
that the message filtering overhead that client 
subscribers experience due to receiving unwanted 
update messages is minimized. Unfortunately, 
this problem contains a solution space that is 
exponential in the number of publications, sub- 
scribers, and multicast channels involved. 

Detecting Multiply-Subscribed Queries — 
Because the general multicast-channel assign- 
ment problem is too difficult, we must resort to a spe- 
cial-case approach for solving a limited form of 
the problem. Based on our experience with a col- 
lection of location-aware applications, we first 
note that the AMS load is determined largely by 
regional or object-specific queries that are issued 
by large numbers of clients as well as by queries mon- 
itoring locations with frequently changing con- 
tents, for example, meeting rooms and hallways. 
In contrast to these "hot spots" of activity, moni- 
toring a single located-object as it moves from 
one place to another in a human time -frame pro- 
duces only light message traffic. Our second 
observation is that, in most cases, many clients 
will specify the same or very simitar subscription 
queries for a particular meeting or for their 
regional and object-specific subscription queries. 

The AMS can exploit these situations by recog- 
nizing when multiple clients are specifying the 
same subscription query and employing a multi- 
cast channel to service the update traffic for that 
query. This approach imposes no additional fil- 
tering overhead on clients and reduces server and 
communication system load to the extent that clients 
can be encouraged to employ the same subscrip- 
ti n queries. In particular, if many clients specify the 
same query for their subscription to a particular loca- 
tion, then meetings can be handled efficiently because 
the AMS can assign a single multicast channel to that 
query and can use it to send a single update mes- 



sage to all the die nts who submitted that query. Sim- 
ilarly, if many clients specify the same regional 
subscription quexy.then.ihe AMS can service 
those subscribers via a single multicast channel 
that is dedicated to them. — 

A more detailed description of how this approach r > 
works is useful. First we observe that we require a 
slightly different mapping than the one we have-- 
already definecTS'pecifically, we define *,(t): u q (t) 
_> c, which maps update query sets to multicast chan- 
nels (instead of the associated update client sets). 
This is so that we can M collapse" clients of multi- 
ply-subscribed queries together. We define Af s {t) 
by defining an equality relationship for subscrip- 
tion queries, such as string equality for the 
(ASCII) source representation of queries, and 
then defining A s such that at all times, /, equal 
subscriptions map to the same member of G and 
unequal subscriptions map to different members 
of G. The size of G is assumed to be sufficiently large 
to allow this. 

The AMS computes ««,(*) by maintaining a 
count of the number of current subscribers who have 
submitted any given query and assigns multicast chan- 
nels to those with more than some pre-specified min- 
imum number of subscribers, q. In particular, the 
AMS maintains a record for each different query 
corresponding to a currently submitted client 
subscription. 4 This record contains a count field, 
a multicast channel identifier, and a list of all 
clients that have submitted this query. A unique uni- 
cast callback address is also maintained for each 
client. The count corresponds to the number of clients 
who are currently interested in that particular 
subscription query. If the count for a query is 
equal to or above q then the multicast channel 
identifier is used to send update information to 
all the relevant clients. If the count is less than? then 
update information is disseminated using the list 
of client callback addresses attached to the 
record. When the AMS receives a new subscrip- 
tion request that contains the<H n instance of a query 
it assigns a multicast channel to the query, records 
the channel's identifier, and notifies all clients 
subscribing to the query to listen to the new mul- 
ticast channel for update information. It does so using 
the list of unicast callback addresses attached to 
the query record. 

Detecting multiply-subscribed queries will only 
work well if clients actually specify the same queries. 
To encourage this we can define a "standard" set 
of query templates that axe parame te rizable by loca- 
tion as well as by a standard set of located-object 
attribute types. When two clients subst itute the same 
parameters, e.g., because they are at the same 
location, then identical queries will result. This 
provides a fairly flexible set of queries that can 
still be easily recognized and mapped to appro- 
priate multicast update channels by the AMS. 

Clients can be further encouraged to use standard 
queries by having applications offer them as easi- 
ly selected options in their user interfaces. For exam- 
ple, the locations program can offer appropriate 
regional queries as menu options for determining 
which located-objects to display information 
about. Standard located-object types might 
include printer and person and common filtering 
criteria might include color vs. black-and- 
white for printers and various region-specific orga - 
nization and work group names for people. 



Finally, we observe that clients sometimes wish 
to subscribe to several standard queries simulta- 
neously. Although we have not implemented it in 
our system, one can imagine allowing disjunctive 
combinations of standard queries so that clients 
can succinctly specify subscription queries that match 
one of several standard query alternatives with- 
out having to manually issue several independent 
subscriptions. This could be done if the AMS 
internally "disassembles" such queries into their dis- 
junctive parts; however, it would require that clients * 
be prepared to receive duplicate update messages 
since multiple query parts may match against the 
same located-object update. The AMS could pro- 
vide support for duplicate suppression by includ- 
ing the same unique sequence number in all messages 
that correspond to the same update. 

Detecting Recurring Update Query Sets — 
The previous section describes how updates toclients 
subscribing to the same queries can be dissemi- 
nated with a common multicast channel. This sec- 
tion presents the idea that when different queries 
result in updates to the same set of clients, they can 
also share a multicast channel. For this to happen, 
we must recognize recurring update query scis r u q (/); 
i.e., sets of non-identical subscription queries that 
repeat across a number of update events. This 
will occur in situations where different groups of 
clients want different, but possibly overlapping, 
"cuts" of a large amount of location information that 
is available for a particular location or region. As 
an example, consider a large mul ti-organization con- 
ference that is taking place. Many members of 
each organization may want to see only the loca- 
tion information pertaining to their own organi- 
zation and, perhaps, a few "sister" organizations, 
rather than information about all attendees of the 
conference. This will be especially true for clients 
sitting on small hosts connected via slow commu- 
nications links. Regional queries can be similarly 
specialized. 

A side benefit of recognizing recurring query 
sets is that it allows the AMS to use a simpler 
form of query equality for recognizing multiply-sub- 
scribed individual queries. Two queries whose source 
form does not match, but which specify the same log- 
ical query, will always appear together at the level 
of query sets. For example a query (key = 
•type," value = * person * ) and a second query 
having(key * "type,' value = -per- 
son") and (key = "department,* value 
= * legal*) are not identical but match the 
same located-objects when ail people at the query 
location are from the "legal" department. 

To detect recurring update query sets, the 
AMS roust keep a history of the update query 
sets that it has computed in the past. When a new 
update event occurs (at time r), the AMS com- 
putes its update query set, u q (t), and then search- 
es its history of update query sets to see if the 
same query set has occurred before. If it has occurred 
several times before then it is a good candidate 
for having a multicast channel assigned to it so 
that updates to that set can be handled with a sin- 
gle update message. More precisely, the AMS keeps 
a list.H.of maximum stzem, of previously computed 
query sets. Each list element contains the repre- 
sentati n for a previously computed query set, a 
count f the number of times the AMS has encoun- 



tered this particular query set, and a multicast 
channel identifier. Just as with individual query 
records, if the count for a query set is equal to or 
above the pre-specified value, q, then the multi- 
cast channel identifier will designate a multicast 
channel that can be used to disseminate update 
information. If the count is less than q then the 
multicast channel identifier will be ni 1. 

When no multicast channel has-fceen assigned 
to an update query set, update information must 
be disseminated separately to the subscribers of each 
query in the query set. This is done as follows: for 
each query in the query set, send out update 
information using either the multicast channel or 
the list of unicast addresses that is associated with 
that query. We shall refer to this means of update 
as the multiple-messages-per-query algorithm in the 
rest of this section. 

The exact steps the AMS performs for an 
update event occurring at time t are given below: 

1) Compute « 9 (r). 

2) Search for an exact match of u q (t) in the his- 
tory list H. An exact match occurs when each 
query in u q (t) is equal to exactly one query in a 
candidate query set, Hj. Matching can be done 
efficiently by using a hash scheme to reduce the 
number of potentially equal query sets in H to one 
or a few candidates. Equality matching of query 
sets is done using representations that have been 
sorted into a canonical order. 

3) If no exact match is found then u q (t) is added 
to the front of H with a count of 1 and anil 
multicast channel identifier. If thiscausesthesizeof 
H to exceed m then the least recently used query 
set is discarded from the list. We maintain a dou- 
bly linked list of query sets in which an item is 
moved to the front of the list on each use.This makes 
the query sets sorted in the order of their last use, 
and the item at the rear of the list is the one we 
discard. Update information is sent to clients 
using the multiple-messages-per-query algorithm. 

4) If an exact match is found — suppose it is 
element//, — then the following steps are performed: 

a) Increment the count of Hi. 

b) If Hfs multicast channel identifier is not 
nil then use the indicated multicast channel to send 
out update information. 

* c) If Hf's multicast channel identifier is n i 1 
and the count field is less than q then send out update 
information using the multiple-messages-per-query 
algorithm. . 

d) If H/s multicast identifier is ni 1 and the 
count field is exactly <? then perform the following 
steps: 

•Assign an unused multicast channel to the 
query set and assign the channel's identifier to the 
multicast channel field of the query set's record. 

• .For each query in the query set, send out the 

update information as well as the identifier of 
the newly assigned multicasi'group using the mul- 
tiple-messages-per-query algorithm. Clients 
are expected henceforth to listen to the designated 
multicast channel for all future update infor- 
mation.? • 

Given the ability to detect both multiply-subscribed 
queries and recurring update query sets, one 
might wonder how important each scheme is to load 
reduction. We observe that in any system that is large 
enough to have a diverse clientele, most of the 
multicast traffic is likely to go over channels that 
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The 
AMS 

guarantees 
never to send 
more traffic 
to a client 
than that 
client's band- 
width limit 
specifies. 



5 Nate that because we use 
reliable multicast, clients 
art guaranteed to find out 
about changes in the set 
of multicast channels they 
should listen to, even if 
they miss tltc relevant 
multicast message. How- 
ever, cart must be taken 
to ensure that when a 
client detects a missed 
multicast message that 
contained such informa- 
tion, the client asks for all 
relevant messages that 
might have been sent out 
already via the new multi- 
cast channel. 



belong to the recurring query set scheme. However, 
trackingmultipry-subscribedqueries allows the query 
set scheme to avoid sending targe numbers of 
unicasi update messages when a query set does 
not end up using a multicast channel for update 
dissemination. Indeed, if only one scheme could 
be used, then as a result tracking multiply-subscribed 
queries would be preferable to tracking recurring 
update query sets. 

A Bandvridth-Liinited Approach 

For clients sitting on low bandwidth communication 
links or for hosts with limited computational resources 
available for "ancillary" applications (such as the 
locations program) the question of how to limit AMS 
update traffic is extremely important. If a client waits 
until a communication channel is flooded with 
updates before taking any action, then it will be 
difficult to send a message adjusting to a "small- 
er" subscription. Unfortunately, it is not easy to infer 
the amount of traffic that any given AMS subscription 
query will generate since circumstances can 
dynamically change. 

The AMS can service such clients best by allow- 
ing them to specify their desired bandwidth limits 
as part of their subscriptions. The AMS guaran- 
tees never to send more traffic to a client than 
that client's bandwidth limit specifies, even if it means 
not sending all the update information that the client's 
subscription query has matched. In order to alert 
clients when they are missing update information 
because of bandwidth limitations, we must add an 
additional count field ( in order to update messages) 
that indicates how many updates are still pend- 
ing. Clients receiving an update message with a non- 
zero count field know that they have received the 
latest available location information for any 
object that is included in the update message, but 
they may be unaware of the latest changes to any 
object not mentioned in the update message. It is 
up to each client to decide how to deal with par- 
tial update information. 

The effect of bandwidth-limited subscription 
on our multicast update schemes is as follows: instead 
of using a single multicast channel for each multi- 
ply-subscribed query or recurring update query 
set we now use b+ 1 multicast channels, where b 
is the number of different bandwidth limits that have 
been specified for the relevant individual query 
or any of the queries in the relevant recurring 
query set. Each of the 6+ 1 multicast channels is used 
to send a different "band" of update traffic fora query 
or query set. For example, if bandwidth limits b { 
andb 2 have been specified for a query then we employ 
three multicast channels, m h m 2 , and my The 
first b\ bytes of update traffic in any given second 
will be sent via m v If any traffic is still available 
for sending during that second then b 2 - b x bytes 
of it are sent via /n 2 . Any remaining data is sent 
via my Clients desiring bandwidth limit b x are 
told to listen only torn,. Clients desiring limit b 2 
are told to listen to both m , and m 2 . Clients with 
no bandwidth limit are told to listen to all three 
multicast channels. 

By using different multicast channels in the 
fashion described, the AMS only has to send out 
an update message once instead of b times. The price 
paid for this approach is that clients must be told 
more often of new multicast addresses to listen 
to; in particular, whenever a new client shows up with 



a different bandwidth limit than has already been 
seen for their subscription query. Since informa- 
tion about all but the first multicast channel to assign 
to a query or query set can be disseminated using 
an already assigned mullicastchannel, this overhead 
is not really a problem. 

Availability ~ " _ - 

Our design refieson a centralized active map 
server, implying that the AMS will stop function- 
ing whenever the server crashes. This is not a 
problem in practice for two reasons: 

• The active map server is host-independent and 
hence can be run on any available server machine. 
A distributed watch-dog facility can monitor 
and restart the server if it fails. 

• A well-known multicast channel can be used to 
allow a newly restarting server to obtain cur- 
rent location information for all located -objects 
currently in its region. All clients of the AMS are 
expected to be listening to this channel address 
and will re-register their location and re-submit 
their subscriptions with the AMS whenever 
they receive a Server -Res care message. 
The result of this approach is that the active map 

server does not stay down for very long, assuming 
that the system makes two or more machines 
available as potential server hosts. 

We have not addressed the issue of partition- 
ing an AMS region. One can imagine AMS clients ' 
starting up new instances of the server in their 
partition when they notice its absence and having 
servers watch for each other (e.g., using the well- 
known multicast channel mentioned above) and per- 
form re-integration whenever partitions heal. 
However, this represents future work. 

One might be templed to avoid the availability 
issues of a centralized service altogether by trying 
to implement the AMS as a distributed communi- 
cations protocol for exchanging information between 
changing location-based objects and interested 
clients. Located-objecis could multicast their update 
information and clients could multicast queries to 
find out what they need to know about the cur- 
rent state of some part of the system. Unfortu- 
nately such an approach will, in general, impose more 
filtering load on the system's loeated-objeel man- 
agers and clients because there is no centralized "traf- 
fic router" that has extensive knowledge about 
who is interested (and more importantly, not 
interested) in what. Given the need to avoid over- 
loading weak clients and slow communication 
links, we consider the disadvantages of a totally 
decentralized design to outweigh its advantages, 
especially given the ability of our centralized server 
to quickly recover from failure. 

Local-Scope Versus Internet Multicast 
Groups 

The assumption that applications can use large num- 
bers of multicast groups is currently not reason- 
able in a general Internet setting: dynamic global 
address assignment is difficult and significant 
numbers of Internet-wide multicast groups would 
overload the routing tables. Fortunately, most AMS 
clients are likely to reside on hosts local to the 
AMS' region. Therefore by limiting the range of mes- 
sages sent over a multicast group — for example, 
to a campus — the same group can be "recycled" and 
used from one campus to the next. 
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Currently we limil the range of IP multicast 
datagrams by setting their time-to-live (TTL) 
parameter: multicast datagrams are forwarded 
from one subnet to another only if their TTL is above 
a certain threshold. A small drawback with this 
approach is that AMS regions must correspond to 
the TTL regions defined by the multicast network 
routers thai will be used (or that the nerwork routers 
have their TTL region definitions be appropriate- 
ly tuned). 

Because some clients may reside on remote hosts, 
an AMS cannot rely solely on local-scope multi- 
cast groups to disseminate heavily subscribed updates. 
In many cases, simply unicasting the relevant updates 
to the one or two remote clients interested in 
them is sufficient (in addition to disseminating them 
via local-scope multicasts). 

If each AMS obtains one or a few Internet 
multicast group addresses for itself, then these 
can be used to alleviate load in cases where a sig- 
nificant number of remote clients exist and are inte r- 
ested in heavily subscribed updates. This works 
well to the extent that fewer Internet multicast groups 
are needed than the AMS has obtained for itself. 
As the demand for additional Internet multicast 
groups increases, the AMS can control its own 
load by reusing each Internet multicast group for 
multiple multiply-subscribed queries or recurring 
query sets and forcing remote clients to assume 
additional filtering overhead. Note that the use of 
Internet multicast groups can be kept completely 
separate from the AMS* handling of local clients 
via local multicast groups (as long as clients' 
"remoteness" can be readily determined). Hence 
the problems of dealing with remote clients need 
not affect the local system. 

Dealing With Unicast Wireless Links 
Many wireless communication technologies — such 
as current cellular telephone systems — do not offer 
multicast support. An agent-based implementa- 
tion for routing packets to mobile hosts also 
makes the provision of multicast difficult since agents 
communicate with their mobile hosts in an essen- 
tially unicast-based fashion. 

A hybrid scheme can help somewhat for sys- 
tems that do not support multicast semantics 
acrosstheirwirelesscommunicaiions links: the AMS 
still employs multicast to reduce its own load; 
however, communications are directed at agent 
processes on LAN-connected hosts that convert the 
multicast traffic to unicast and forward it to the 
actual client applications running on mobile 
hosts. Unfortunately this does not alleviate the 
load problems that occur when the same update mes- 
sage gets sent separately to many clients residing 
in the same slow, wireless communications cell. 

This problem can be partly alleviated by mov- 
ing the relevant client applications partly or whol- 
ly to stationary hosts that are directly connected 
to a multicast-capable nerwork. if a suitable local 
host is available then this may not be difficult and 
may even simplify matters: complicated filtering 
needed to cull a small, manageable amount of 
information from the update traffic generated 
during overload situations can be done on a 
faster stationary machine instead of on a slower, 
resource- and power-conscious, portable machine. 
The final information results, which will presumably 
be much smaller in size than the original update 



traffic, can then be sent to application "front-ends 
that reside on users* portable machines. 

In some cases however, a suitable local host may 
not be available. While a mobile user is in his "home" 
AMS region he will likely have access to a trusted 
workstation or server machine on which to safely run 
his applications. If the user visits a remote region 
he may not have access to a suitable Jocal machine 
there and would be forced to run his applications 
remotely on a machine in his home region. 
Depending on the applications and networks 
involved, the additional delays this would impose 
may or may not be an issue. In general, we conclude 
that, while unicast wireless links can be partially 
dealt with — especially when clients have access 
to local trusted hosts — the availability of multi- 
cast on wireless links is far preferable as a basis 
for an AMS system. 



An Implementation 



In our laboratory we currently have two imple- 
mentations of the AMS running: an older ver- 
sion of the system has been in production use by about 
40 people for several years and a new version 
exists for use in a simulated testbed environment. 
The latter was built in order to explore the ideas pre- 
sented in this article and all the results presented 
in this section were obtained from it. 

The testbed system we built was designed to 
tell us two different things: how well the active 
map server we built works and what kinds of 
loads might occur under various different user 
movement scenarios. In particular, we were inter- 
ested in characterizing the behavior of the system 
under "norma!" load circumstances as well as when 
a meeting of many people took place. 

Figure 2 shows some micro-benchmark num- 
bers for our AMS testbed. These measurements were 
made onaSunSparcSlation-2client, communicating 
using Sun RPC over an Ethernet to a SpaxcStation-2 
server machine running the active map server. 
The line marked "query match" shows the time 
required to match a simple query against a collec- 
tion of AMS objects with a single object being 
successfully matched and returned to the query client. 
The slope shows that each additional object matched 
contributed about 66 *ts to the service time. The 
line marked "query return" shows the cost of return- 
ing objects whose size is around 400 to 500 bytes 
io the client . 6 The slope of the line indicates about 2.5 
ms are needed for each additional object returned. 
The line marked "subscriber update" shows how 
AMS service time for unicast subscriber updates 
depends on the number of messages that must be 
sent to disseminate information about an update 
event. 

To see how our system might behave under 
different usage scenarios we built an artificial 
workload generator, SimMob, for producing sets 
of sightings that can thenbe played back toour active 
map server. The workload generator is a discrete 
event simulation of user movement consisting of 
multiple "people" moving from vertex to vertex 
on a graph representation for a building. The 
building we simulated consists of multiple copies 
of the floor plan for our laboratory. Each person 
has a transition probability matrix (called a 
"mode") and a rate of transition. Activities, such 
as a meeting, that occurs during the workload 
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I Figure 2. Micro benchmark numbers for an active map server running on a 
SUN Sparcsiation-2. 



simulation can change the mode and rate for one 
or a group of people. Our workload generator knows 
about paths and distances: the main simulation loop 
chooses a destination based on the users mode 
and lakes this destination and expands it to the 
sequence of steps (i.e., sightings) along the short- 
est path. These sleps are then emit ted at times based 
on the step's distance and a global travel-rate. 
Once a move is complete, the workload generator 
chooses a Poisson-distributed random sleep time 
(based on move-rate) for the person and leaves 
that person stationary for that length of time 
before repeating the entire process again. 

Using S imMob we are able to build artificial sight- 
ings of hundreds of users in hundreds of loca- 
tions. To test the AMS we designed two types of 
workloads, **meeting" and "normal." The meet- 
ing workload has people start in individual locations 
and at some point converge on a single location over 
a specified period of time, typically about 3 to 5 
minutes. The normal workload has users spend most 
of the time in their offices and every once in a 
while venture out to another location. 

To see how large a normal work community might 
be handled by the AMS we ran a normal work- 
load against a unicast version of the AMS with 
1,000 users in the system. As input to the work- 
load generator we used an 80 percent probability 
of staying in the office location which resulted in 
12 percent of the community being mobile at any 
given time, on average. This translated into 
mobile users being sighted an average of every 
8.9 seconds, resulting in a computed average of 
600 moves. per minute overall. The generated 
workload was executed on 18 SparcStation hosts 
each with between 55 to 56 client processes, 
along with hosts for the server and a monitor pro- 
gram. Running the workload produced updates 
at the expected rate, with encounters with other peo- 
ple occurring on about 40 percent of the moves. 
No regional queries were included in this work- 
l ad; users monitored only their own locations. 
For the unicast design we observed an average delay 
of 23 ms in receiving updates — about twice the 
unloaded case of 1 1 ms — implying that the AMS 
should easily be able to handle in excess of 1 ,000 users 
under M n rmal work" conditions. 



6 The reasons why local - 
ed-objects in our system 
are so large are twofold: 
descriptions consist of sev- 
eral attributes and we use 
the relatively inefficient 
Sun XDR facilities to 
encode object descrip- 
tions. Although one could 
significantly reduce the 
size of object descriptions 
it would not qualitatively 
change the results we 
obtain, indeed, by using a 
targe object size we obtain 
conservative bounds for 
how well our system 
should perform: using 
smaller object sizes would 
only improve things. 

7 If update query set sizes 
were to start numbering in 
the many tens to hundreds* 
then the cost of sorting 
them uuo canonical order 
and storing them would 
stan to be significant. 
However, our whole 
design is predicated on the 
assumption that many dif- 
ferent queries will not 
match any given update 
event. 



To confirm the fact that things like meet- 
ings will quickly_pverloa_d a unicast design, we 
also ran several meeting workloads against our 
unicast version of the AMS. Figure 3 shows our 
results, indicating thai meetings with more than . 
about 50 participants started to produce exces- 
sive move-response times. In contrast, a single 
multicast channel version of the AMS seems 
able to support meetings of up to about 530 
participants. 

The overall performance of a version of the 
AMS that incorporates the multiple multicast 
schemes described in this article is determined 
primarily by the average numberof update messages 
that the server ends up sending out per update event. 
That is, the cost of managingthe data structures need- 
ed for these schemes is small compared to the 
cost of actually sending update messages out on 
the network. 7 When users employ standard 
queries the way that client applications try to encour- 
age them to, the average number of messages 
that the AMS must send out for an update event 
is kept quite low. Indeed, for most update events, 
a single message suffices to update all regional 
subscriptions. The same is true for subscriptions 
to meeting locations. Unfortunately, only produc- 
tion use of our system by real users who have had 
a chance to write new applications will tell us how 
many non-standard subscription queries will 
occur in practice. 

Figure 4 illustrates how the maximum size of 
meetings handled by the AMS server depends on 
the average number of messages that must be 
sent out per update event. The values were 
obtained by disabling the use of multicast chan- 
nels for identical clients sets and generating arti- 
ficial meeting workloads with a different numbers 
of distinct subscription queries. In this graph, the 
maximum meeting size is the point at which the AMS 
is receiving updates quicker than they can be dis- 
seminated. The graph shows the potential benefit of 
merging client update sets into multicast channels 
over the use of query matching alone. 

Related Work 

Asmentioned at the beginning of this article, there 
have been a number of papers on the topic of 
location-based systems, including [4, 1 1-14). (4) is 
perhaps the broadest and most recent overview avail - 
able on the topic. The distinguishing feature of 
the work presented here is that it is the first that 
addresses the issues of scaling and overload con- 
ditions for systems covering "medium-sized" regions, 
such as buildings and small campuses. 

Our work can take advantage of several lower- 
level communications technologies that have 
been, or are being, developed by others. These 
include lP-multicastJ3), mobile IP[5), and mobile 
IP multicast! 1). 

A number of other systems also use a publish/ 
subscribe style of information dissemination, 
most notably [9] and [8]. However, all these sys- 
tems employ only broadcast or at most a few mul- 
ticast groups for their implementation, resulting 
in extensive client-side filteringof messages. In con- 
trast, our approach aggressively employs large num- 
bers of multicast groups in order to keep client 
filtering overhead and slow communication link loads 
to a minimum. 
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Summary and Conclusions 

This aniclc describes an active map service thai 
supports context-aware computing by providing 
clients with information about locaied-objects 
and how those objects change over time. We 
focus on the communication issues of disseminating 
information from an active map server to its 
clients, and in particular, we address how todeal with 
various overload situations that can occur. Simple 
unicast callbacks to interested clients work well 
enough if only a few located-objects are moving 
at any given lime and only a few clients wish to 
know aboul any given move. However, if many 
people are moving about in the same region and 
many clients are interested in their motion, then 
the AMS may experience overload due to the quadrat- 
ic nature of the communications involved. This over- 
load affects both the server as well as any slow 
communications links being used. 

Generated workloads illustrate the extent of 
the potential overload problem: while our system 
seems capable of handling in excess of 1,000 users 
under "normal" low-load circumstances (exem- 
plified by people mostly sitting in iheir offices), 
meetings of more than about 50 people manage 
to overwhelm it if they are handled only by means 
of unicast communications. In contrast, when the 
AMS employs multiple multicast groups it is able 
to support meetings of more than 500 participants. 

Our approach to this problem has been to 
exploit multicast techniques in order to avoid requir- 
ing the AMS to repeatedly send out the same update 
information message to different receivers, in order 
to avoid losing update information, we use reli- 
able multicast channels, which require clients to mon- 
itor sequence numbers in each multicast message 
and request retransmissions whenever they detect 
a missed sequence number. 

In order lo avoid increased client filtering 
overhead and added overhead on slow communi- 
cations links, we use multiple multicast channels 
so that AMS clients see only the subset of AMS 
updates they are interested in. Assigning multi- 
cast channels to suitable subsets of the update 
traffic in order to minimize system load is, in gen- 
eral, a very hard problem. The special-case solu- 
tion we have pursued is to recognize subscription 
queries that have been submitted by multiple clients 
and sets of subscription queries that match multi- 
ple update events. This approach is based*>n two 
observations about AMS load: it is generated 
mostly by regional queries that are submitted by large 
numbers of clients and by update traffic related 
to a relatively small number of "hot spot" loca- 
tions or objects. 

To encourage the use of the same queries by many 
clients, we have structured our applications to 
offer standard queries as easily invoked menu 
options. Structuring applications in this fashion 
can sharply increase the likelihood that many clients 
will employ Ihe same query. The ability to tailor both 
the AMS and its clients is perhaps the key factor that 
enables our design to succeed. In essence we 
ensure that our load reduction schemes will work 
well by making sure that most client applications 
generate exactly the kinds of queries the schemes 
are designed to handle. If AMS applications were 
designed without keeping this in mind, they 
might well not exhibit the regular patterns that 




Figure """e update time for clients monitoring a meeting as a function 
of meeting size. 
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the AMS depends on for controlling system load 
While tailoring applications to behave properly 

is key to our design, we feel that it is important to 

offer as much flexibility to clients as possible 

within the confines of our design. For example 

because the recognition scheme used by the AMo 

dynamically recognizes multipry-subscnbed queries, 

applications can change the set of standard 

queries they employ without having to change or 

even notify the AMS itself. We also do not out- 
law - non-standard" queries in our design. 

Another important feature of our design is its abil- 
ity to strictly limit the update traffic that clients 
will be exposed to if they desire such a limit. By allow- 
ing clients to explicitly specify bandwidth limits 
for the AMS update traffic, we avoid being 
"blocked out" on a slow communications link 
from other more important application traffic 
and from inadvertently consuming all of a power- 
conscious host's resources. 

Although we pursued a centralized design for the 
AMS. we do not feel this causes an availability 
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problem since the active map server is hosi-inde- 
pendent and hence can be restarted on any available 
server host. Restarting a server can be done fairly 
quickly by using a well-known multicast group 
address to solicit location and subscription infor- 
mation from all clients in the system. As a consequence, 
we have not felt the need to explore more com- 
plicated and expensive fully-decentralized designs. 
However, future work remains 10 be done on deal- 
ing with partitions of an AMS region. We hope to 
explore an extension of our centralized design 
that relies on dynamically creating servers for 
each pa rtition and then u merging" servers when par- 
titions heal. 

Because most clients of the AMS are expected 
tobe local to the region it covers, the AMS uses local- 
scope multicast groups to reach local clients, 
thereby avoiding the difficulties of using large 
numbers of Internet multicast groups that must 
be globally allocated and managed; unicast is 
used to reach remote clients. We do not yet have 
experience with significant numbers of remote clients. 
If remote clients remain rare, then use of a small pre- 
allocated set of Internet multicast group address- 
es per AMS region may suffice for dealing with ihem 
more efficiently than unicast would. However, if 
activities such as telecommuting make them com- 
mon, (hen our design could become problematic 
if AMS regions cannot obtain large numbers of 
easily managed Internet multicast group address- 
es for their private use. 

Finally, we observe that our approach to dis- 
seminating information relies on the availability 
of multicast throughout a system, including its 
wireless communication links. While multicast 
can be added in a straightforward manner to the 
experimental infrared and radio facilities that we 
have built in our lab, it is not readily available as 
part of the current commercial cell phone infras- 
tructure and is not yet a part of any mobile IP 
protocol proposal. While we have described an agent- 
based approach that enables a system with only 
unicast-based wireless communications to take par- 
tial advantage of our multicast solutions, we 
believe that a widespread deployment of active 
map facilities — or facilities like them — will require 
the widespread introduction of wireless and 
mobile multicast facilities. 
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